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ABSTRACT 

The exchange of models is one of the most serious problems currently encountered in the practice 
of spacecraft thermal analysis. Essentially, the problem originates in the diversity of computing 
environments that are used across different sites, and the consequent proliferation of native tool formats. 

Furthermore, increasing pressure to reduce the development’s life cycle time has originated a 
growing interest in the so-called spacecraft concurrent engineering. In this context, the realisation of the 
interdependencies between different disciplines and the proper communication between them become 
critical issues. 

The use of a neutral format represents a step forward in addressing these problems. Such a means 
of communication is adopted by consensus. A neutral format is not directly tied to any specific tool and it 
is kept under stringent change control. Currently, most of the groups promoting exchange formats are 
contributing with their experience to STEP, the Standard for Exchange of Product Model Data, which is 
being developed under the auspices of the International Standards Organization (ISO 10303). 

This paper presents the different efforts made in Europe to provide the spacecraft thermal analysis 
community with a Thermal Neutral Format (TNF) based on STEP. Following an introduction with some 
background information, the paper presents the characteristics of the STEP standard. Later, the first efforts 
to produce a STEP Spacecraft Thermal Application Protocol are described. Finally, the paper presents the 
currently harmonised European activities that follow up and extend earlier work on the area. 


ABBREVIATIONS AND TERMS 

AAM Application Activity Model 

AIM Application Interpreted Model 

ARM Application Reference Model 

ANSI American National Standards Institute 
AP Application Protocol 

ASCII American Standard Code for Information Interchange 
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ATS Application Thermique Spatiale 

CAD Computer Aided Design 

CAE Computer Aided Engineering 

CNES Centre National d'Etudes Spatiales 
ECLS Environmental Control and Life Support 
ESA European Space Agency 

* ESARAD ESA's radiative analysis software 
ESATAN ESA's thermal network analyser 
ESTEC ESA’s European Research and Technological Centre 
re Finite Elements 

FHTS Fluid loop extension to ESATAN 

FLUOR CNES’ Radiative Analysis Software 

ICETAS Integrated Communication Environment for Thermal Analysis 

IGES Initial Graphics Exchange System 

IR Integrated Resources 

ISO International Standards Organization 

SDAI Standard Data Access Interface 

SET Standard d'Exchange et Transfert 

TAS Thermal Analysis for Space AP 

STEP ISO's Standard for Exchange of Product Model Data 

TMM Thermal Mathematical Model 

TNF Thermal Neutral Format 

VDA-FS Verband Deutschen Automobil, Flaechen Schnittstelle 
YC ESTEC’s Thermal Control and Life Support Division 
YCV YC’s Analysis and Verification Section 


THE THERMAL NEUTRAL FORMAT 
Standardisation of the analysis tools 

The standardisation of analysis procedures has become an essential requirement for the 
organisations operating in the European Space sector, due to the complexity found in large space projects 
involving international consortia of companies. This standardisation has most obviously materialised in the 
availability of a set of de facto standard tools which facilitate the interaction between the different parties 
involved in a project. Examples are the ESABASE (ref. [1]), ESATAN (ref. [2]), FHTS (ref. [2]), 
THERMICA (ref. [3]) and the recently released ESARAD (ref. [4]) tools. 

An important consequence of this situation is that the tool’s native formats have also been adopted 
as the de facto standards for exchange and archive of thermal models. This seemed quite convenient at a 
time when the number of tools was small and no obvious alternative was available. However, this approach 
is not satisfactory any longer. In fact, the use of native formats has serious and long reaching implications, 
which will be reviewed in the following sections. 
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The problem of exchange 

i 

The exchange of thermal models is currently posing a number of serious problems to the day-to- 
day practice of the spacecraft thermal analysis. Essentially, the problem originates in the diversity of 
computing environments adopted by different organisations, and the consequent proliferation of native tool 
formats. The situation can be even more troublesome for those organisations needing to maintain several 
environments to serve different requirements or customers. 

Furthermore, the organisations often invest in the development of proprietary software, which is 
normally intended to serve purposes not adequately covered by the standard tools. These developments 
contribute to enhance the companies' competitiveness, by taking advantage of in-house expertise and skills. 
However, most of these tools introduce new exchangeability requirements, aggravating further the problem. 


The concurrent engineering issue 

A state-of-the-art analysis environment cannot overlook the need to provide proper communication 
means between the different teams involved in the spacecraft development. Indeed, spacecraft engineering 
is a true multidisciplinary process, in which the information follows complicated paths and different 
disciplines interact in non-trivial manners. 

Traditionally, each discipline’s analysis has been performed in an uncoupled way, in an attempt to 
isolate their particularities and thus to simplify the assumptions and methods used for each of them. 
However, two main developments have radically changed in the last years the context in which the analysis 
takes place: 

• the advances made in terms of computing power have allowed to perform more and more complex 
analysis in a shorter time. Furthermore, this evolution has enabled the development of tools that model 
and analyse the physical problems with fewer simplifications and restrictions. 

• more and more complex missions impose requirements which cannot be achieved by performing 
uncoupled disciplinary analysis. 

With these ideas in mind, there is an increasing trend to acknowledge the interdependencies 
between design and analysis and to integrate them within a tightly coupled process. This approach also 
encourages the concurrent analysis of several physical problems through the use of common models, 
procedures and tools. The final objectives are those of streamlining the flow of information and of 
increasing the efficiency and the capabilities of the design and analysis processes, while rationalising the 
resources used. 

Two issues are particularly important in this context. Firstly, a good communication between the 
CAD world and the analysis environment has become an essential requirement. Indeed, although the flow 
of information between disciplines depends on several organisational issues, the initial stage is typically the 
acquisition of configurational data from the project source, which in general is a CAD system. Secondly, 
proper communication to commercial finite element (FE) packages is more and more important. The 
continuous evolution of these tools in the last years makes them very attractive to both managers and 
engineers. FE packages provide a framework which can be used to integrate individual discipline tools to 
yield the desired multidisciplinary analysis capability. Although finite differences remains the method of 
choice in spacecraft thermal analysis, the drive towards concurrent engineering is likely to foster the use of 
FE tools in the future. 
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The problem of archive 


The exchangeability requirements can be extended quite naturally to the archive and retrieval of 
analysis models and results. After all, one can consider archiving as an exchange across time. Indeed, an 
archived model might not run properly when retrieved because of the evolution of the tool and the 
incompatibility between different versions. An extreme case, but not unlikely given the typically long 
duration of the space projects, would arise when the tools once used in a project are not available (or 
supported) any more. 

A further reason making the case for stable archive means is the need to perform occasional 
emergency analysis campaigns to cope with spacecraft operation modes that follow unexpected events or 
failures. Under the urgency of these situations, costly modifications to the archived models are simply not 
acceptable. 


The need for a neutral format 

It is clear that the use of native formats as a means of exchange brings about serious problems. For 
instance: 

• their use encourages the proliferation of tool-to-tool interfaces. Obviously this is not the most efficient 
way to exchange data between a given number of software packages. 

• native formats are intrinsically unstable, i. e. they evolve with time. Therefore, the software interfaces 
that read/write native formats have to be constantly updated in order to keep up with new versions of 
the tools. 

• the interface developers need to have a complete, updated description of the two formats being inter- 
faced. This might be a problem if, as usual, the interface developers are not in control (at least one) of 
the formats. This fact increases the chances of software interfaces lagging behind the evolution of the 
tools, or simply being obsolete. 

• organisations may have to develop different interfaces to satisfy each major customer’s requirements. 
The extra costs incurred by this practice are frequently absorbed by the customer. 

The use of a neutral format overcomes these serious problems. Such an approach is adopted by 
consensus as a means of exchange and archive. A neutral format does not depend on any specific tool and 
it is kept under stringent change control. The neutral format system consists not only of the description of 
the data intended to be exchanged or archived, but also of a formalism describing the means for exchange 
or archive and of the interfaces to other formats. 

According to ref. [5], a Thermal Neutral Format (TNF) shall fulfil the following requirements: 

• the TNF shall ultimately support the domain relevant to all the software tools used to perform thermal 
analysis. 

• the interfaces in both directions (TNF to native format and vice versa) shall preserve the integrity of the 
information being exchanged or archived. 

• the TNF shall be flexible enough to allow its extension without modification of the existing features. 

• the TNF shall allow the selective treatment of the data. That is, each interface shall be able to process 
only the data relevant to the interface. 

• the TNF shall be portable across systems and sites. 
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A TNF should also benefit of a large scope. Indeed, a widely spread standard formalism should be 
used to support the data exchanged or archived, simply because commercial CAD/CAE and re tools are 
more likely to include built-in interfaces to internationally accepted standard formats. The development of 
a specific formalism for the TNF would not only waste efforts but also limit its immediate scope of 
application. 

Finally, it is important to notice that were a TNF available, the development of interfaces to and 
from the TNF would normally be left to the tool developers themselves. This would likely give better 
chances to have interfaces up-to-date to the last tool versions. 


Initiatives in the field of Thermal Model exchange and archive 

Although the problems described in the previous sections have been around for a long time, the 
development of a TNF, based on a broad consensus within the European Space Industry, has not been 
attempted until recently. However, a number of initiatives were bom with the intention to address the 
problems in one way or another. 

As previously commented, native formats were typically exchanged between sites. The Thermal 
Mathematical Models (TMM) exchanged by means of ESATAN input decks are a clear example of this 
approach. As the need to exchange geometry-based models grew, the requirement for a new format became 
obvious. For that purpose, the ESABASE[4] language started to be used. Although ESABASE is basically 
a system engineering package, its input language provides a means to define analysis-tool-independent 
models. Furthermore, the ESABASE framework includes translators to several radiative and thermal 
packages. However, the ESABASE language depends itself on the evolution of the ESABASE software, 
and it has a rather limited scope. 

Another ESA's initiative, ICETAS (ref. [6][7]), was not originally an effort to provide solutions to 
the problems of exchange and archive. Rather, it addressed the issue of integration of thermal software tools. 
Nevertheless, as work on ICETAS progressed these aspects became very relevant. Furthermore, the project 
produced a description of the complete set of data required to perform Spacecraft Thermal Analysis, as well 
as their interrelationships. This information is clearly very relevant to the development of a TNF. 


The SET-ATS protocol 

An important initiative has recently been undertaken by CNES, the French Space Agency, in order 
to provide a TNF based on the French standard SET. CNES have developed the “Application Thermique 
Spatiale” (ATS) Application Protocol to address the spacecraft thermal analysis exchange and archive 
requirements. 

The first version of the protocol (ref. [8]) provided support for three major categories of entities: 

• geometrical entities extracted from a set of primitive shapes, which are meshed and have thermo-opti- 
cal properties attached to their faces. These entities can be assembled to build hierarchical models con- 
taining multiple occurrences of sub-models. 

• results of calculations (processing) associated to geometric or thermal nodes. 

• an entity containing the data needed to characterise the orbit. 

In addition to these categories, the “neutral file header” and “neutral file summary” entities define 
the required additional information (origin, date of issue ...) for exchange and archive purposes. 
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Following a first implementation and test, a second version (ref. [9]) has extended the original 
protocol to improve the support for: 

• orbit and kinematic extensions. Orbital data locate the satellite, considering it as a point in space (its 
centre of mass). Kinematics data give the attitude of the satellite and its moving parts with respect to 
the planet and the Sun. 

x • geometrical features. The set of elementary surfaces has been extended to take into account boolean 
operations and high-level shapes. The boolean operations (union and difference) can be used to gener- 
ate complex geometry by combining elementary surfaces. High-level shapes, which have an associated 
type (e. g., box, cylinder ...), allow the easy manipulation of collections of elementary surfaces. 

• language features such as comments, numbering and labelling, mainly introduced for man-machine 
interface purposes. 

With this extended support, the new version aims to cover the main capabilities of the FLUOR, 
THERMICA ESABASE and ESARAD radiative analysis software. 

The ATS protocol is based in the data and mechanisms defined in the SETZ68-300 standard, which 
is implemented in a large number of CAD/CAE software packages and used extensively in the European 
Aircraft Industry. The protocol, which covers some domain specific requirements, makes use of a subset of 
the generic entities available in the SET language. Moreover, some items of information, not covered by the 
SET standard, required the addition of new blocks and sub-blocks which can only be used by an interface 
that recognizes their format and semantics. Consequently, a correct SET- ATS interface will generate a SET 
physical file syntactically compliant to the SET standard. A standard SET interface will read these files, 
although it will be unable to interpret the parts of the information specific to the ATS protocol. 


THE STEP STANDARD 
Description of the standard 

Work on communication standards between CAD/CAE systems has been under way since the 
beginning of the eighties, resulting in the development of several exchange formats like IGES, VDA-FS or 
the above mentioned SET. Currently, most of the groups promoting these exchange formats are contributing 
with their experience to STEP[10], the Standard for Exchange of Product Model Data, which is being 
developed under the auspices of the International Standards Organization (ISO 10303). 

STEP was first proposed in 1984, with the intention to provide a worldwide standard supporting the 
complete representation of a product throughout its life cycle. STEP is different to other exchange formats 
in that rather than only providing rules to format a defined set of data, it is also supplying a methodology to 
formally describe the data and to implement the format. Furthermore, conformance testing to the standard 
is an integral pan of STEP. From this point of view, STEP goes beyond the concept standing behind other 
exchange standards, by providing a standardised methodology to define application-specific product data 
standards. Other advantages with respect to existing standards are: 

• because of the broad international consensus built around it, STEP is likely to meet the requirements set 
by many different applications. 

• STEP establishes a separation between the logical design of the data and the physical implementation. 

• the use of a formal language removes ambiguity and enables a rigorous conformance testing. Further- 
more, automatic software generation from the EXPRESS specification becomes possible. 
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STEP consists basically of a series of components (called parts in the STEP terminology). Each of 
the parts are published separately, to help coping with their different degree of maturity. The main pans are: 

• the EXPRESS[11] language, developed on purpose for STEP. EXPRESS is a formal information mod- 
elling language used when describing the STEP entities, with the intention to ensure consistency and 
avoid ambiguity. 

• resource information models defining the basis for the development of application standards. The so- 
, called Integrated Resources (IR) are in fact the basic building blocks used to define the application 

standards. They provide a unique representation of each element of information used within STEP. 
These resources can be either Generic Resources, i.e. of potential use for any type of application, or 
Application Resources, valid only for specific applications. The EXPRESS language is used to define 
the IR. 

• Application Protocols (AP), which are the actual application-oriented standards that end-users will take 
for their exchange and integration needs. The APs are logically self-contained and complete. 

j • implementation methods supporting the data models provided by STEP. 

• strict conformance testing procedures and tools to control and to certify compliance to STEP APs. 

Therefore, the EXPRESS language is used in the definition of the Integrated Resources, from which 
the Application Protocols are derived (these can also use directly EXPRESS). A STEP implementation is 
produced when an Implementation Form is chosen. This implementation can be tested for conformance to 
the standard using the STEP-supplied methodology. 

STEP is also to play a role in the issue of integration. Indeed, there are several possible 
implementation forms of the STEP standard. Today, the only implementation in place is the physical 
transfer file, but work is progressing in the definition of the Standard Data Access Interface (SDAI), which 
will introduce a software layer representing an abstract, “EXPRESS'” view of the data to be transferred or 
stored. The SDAI will provide in practice interfaces to both relational and object STEP databases. 


STEP Application Protocols 

As mentioned previously, STEP provides a standardised methodology to develop protocols 
oriented to specific fields of application. The development of a particular AP stems from the specification 
of the scope and the information requirements of the AP. This is achieved by means of the Application 
Activity Model (AAM), which describes the processes, information flows and functional requirements of 
the application. The AAM helps to understand the nature of the activities and the role of the product data in 
the field of application. The AAM is included as an informative annex to the AP. 

A more detailed Application Reference Model (ARM) specifies the information requirements and 
constraints of the AP, in terms of the so-called Units of Functionality. These units contain information about 
the entities, attributes and relationships that determine a given concept within the ARM. Although the ARM 
is defined by means of a formal data description language, application-specific terminology is used in this 
model. The ARM is also appended as an informative annex to the AP. 

After the ARM is defined, the Application Interpreted Model (AIM) specify the manner in which 
the Integrated Resources can be used to satisfy the AP requirements. The resource constructs can be used 
directly, or refined depending on the application requirements. 

Finally, the APs shall include the conformance requirements to be satisfied by any implementation 
claiming to support the AP. Such an implementation is tested by performing a conformance test based on a 
set of abstract test cases. 
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STEP and the TNF 


Several fundamental STEP parts are already available either as International Standard or Draft 
International Standard. These parts include the EXPRESS language, the Physical File Exchange Structure, 
the conformance testing methodology, some Integrated Resources and some Application Protocols. A 
' significant number of other IR and AP are being developed, with many of them close to achieve a stable 
state. 

Certainly, the transition from current exchange standards to STEP will take some time. 
Nevertheless, enough progress has been achieved to appreciate the relevance of the STEP technology to the 
development of a TNF. Indeed, STEP is an obvious candidate for the TNF, because in addition to its 
intrinsic advantages as product data standard, it fulfils the basic requirements for a TNF: 

• it is a neutral format that satisfies the needs for stability and tool-independence. 

• its broad scope will allow immediate communication to the CAD and FE worlds. 

In summary, STEP provides an excellent methodology to develop a Spacecraft Thermal 
Application Protocol. For the first time ever, the thermal analysis community might have the possibility to 
use a TNF tailored to its needs, but at the same time enjoying the character of full international standard. 


DEVELOPMENT OF THE STEP THERMAL AP 
ONES’ STEP-ATS Application Protocol 

Based on the experience gained in the production of SET-ATS, CNES undertook the development 
of an application protocol using the technology and methods developed for STEP (ref. [12]). 

This application protocol was developed in conformance to the rules put forward in the “Guidelines 
document for development of STEP protocols”. However, the complete process of Integration and 
Qualification imposed by ISO on the 10303 Parts was not followed. In particular, the Application Activity 
Model was not produced. On the other hand, the application protocol was developed by using, as far as 
possible, resources defined in ISO 10303. However, due to the fact that STEP is still in evolution, some of 
the required resources are not yet available in the standard. Therefore, these specific resources had to be 
produced in order to meet the application requirements. With these limitations in mind, the STEP protocol 
was defined to match the user requirements associated to the first version of the SET-ATS protocol. 

The first stage of the development consisted in the specification of the information requirements in 
terms of units of functionality, application objects and application assertions. This stage defines the product 
data as viewed by the application users. The models are specified to have a tree structure including 
occurrences of sub-models. Any sub-model can also contain surface data representing a part of the 
geometry. Information related to the meshing and to the physical properties of each face is attached to the 
surfaces. Moreover, the protocol supports the transfer of the data needed for the orbit determination and the 
results of the thermal analysis. Finally, it includes the information related to the management of the 
exchanged models (designer, creation date, entity labels, colour for possible graphical display, grouping of 
entities into cells ...) 

The information requirements are specified in terms of: 
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• Units of Functionality that allow the classification of the application objects into coherent groups such 
as geometry, thermo-optical properties or model structure. 

• application objects such as surface type, mesh characteristics and orbit parameters. These objects are 
atomic elements that embody a unique application concept and contain attributes specifying the data 
elements of the object. 

• application assertions that specify the relationships among application objects. For instance, “meshing 
of a Thermal_face is defined by one Mesh_characteristics”, “a Mesh_characteristics applies to one 
Thermal_face” or “a Thermal_face has at most one Mesh_characteristics” 

A graphical representation, using the EXPRESS-G notation, describes the structure and constraints 
of these application requirements (see Figure 1). 

Following the definition of the information requirements, the Application Interpreted Model was 
then produced to specify the references to the STEP Integrated Resources. For each Unit of Functionality 
and application object, the so-called Mapping Table shows the correspondence between the information 
[ requirements and one or several AIM resource constructs. 

Finally, the AIM’s EXPRESS annotated listing was produced to present the complete listing of the 
types, entities and rules necessary to fully specify the AP. 

It is important to note that the move from SET to STEP does not only represent a change in the 
neutral file physical format but also demands the evolution of the requirements (or at least of the way to take 
them into account). As a matter of fact, STEP promotes the concept of product whereas SET deals mainly 
with geometrical models. Although the STEP AP development process is more complex, the possible scope 
of the AP is much broader. Furthermore, it encourages an approach which is consistent with data 
representation requirements appearing in other stages of the spacecraft design. 



FIGURE 1 . EXPRESS-G diagram presenting the information related to the 
Model_structure unit of functionality 


I 
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Thermal Analysis for Space AP 


The independent efforts undertaken by CNES and ESA in 1993 had similar timing and objectives, 
since both intended to produce a STEP Application Protocol for Spacecraft Thermal Analysis. Thus, it 
seemed reasonable to start a harmonisation process in order to reduce the chances of duplicating work. 
Furthermore, it seemed sensible to rationalise the efforts by making an efficient use of the knowledge gained 
by both CNES and ESA in the matter. 

This harmonisation was fully achieved in early 1994 in the form of an activity to develop an 
Application Protocol on Thermal Analysis for Space (STEP-TAS). Previous experience coming from the 
STEP- ATS and the ICETAS projects was directly fed into the new project. 

The harmonised work set off with the fundamental objectives of: 

• merging the domain information models developed independently by CNES and ESA. Consensus in 
the Application Activity and Application Reference Models will result from this merge. 

• extending the AIM developed by CNES to support a subset of the domain information requirements 
mentioned above. 

• demonstrating the exchange of thermal models via STEP files. For that purpose a prototype facility is 
being developed to communicate FLUOR and ESARAD. 

Results produced in the first stage of the harmonised effort are expected towards the end of 1994. 


CONCLUSIONS 

The concept of neutral file contributes in a very significant way to streamline the exchange of 
information, as proved by the development and use of the SET-ATS protocol. Modern product data 
technology, commonly associated to STEP, ensures the development of non-ambiguous domain-specific 
protocols which provide solutions not only to the information exchange problems but also to the integration 
of applications. However, the matter of successfully introducing a TNF in the spacecraft thermal analysis 
community remains largely a problem of consensus. Currently, a harmonised effort CNES/ESA is under 
way to provide a unique description of the information requirements in this domain. If an agreement is 
reached on the suitability of this logical description, the STEP technology is ready to produce an 
implementation of the TNF. 


REFERENCES 

[1] ESABASE User Reference Manual, ESA/ESTEC/WMA 

[2] ESATAN User Manual. ESA PSS-03-105 Issue 2, November 1991 

[3] THERMICA User’s Guide. Matra Marconi Space, 1991 

[4] ESARAD v2.1 User Manual, UM-ES ARAD-024, EGT/MEC, 1993. 

[5] Definition of the Common Structure of Data to Promote the Communication Between Different Thermal 
Software Tools. B. Desaunettes and C. Viguier, Proceedings of the 4th European Symposium on ECSS ESA 
SP-324, October 1991. 


272 


[6] Integrated Communication Environment for Thermal Analysis Software - Phase 2. H. P. de Koning et 
al., 24th ICES Conference, June 1994. 

[7] ICETAS Standards Document, SID-ICETAS- 

009, H. P. de Koning et al., Fokker Space & Systems. 1994. 

[8] Protocole d’ Application Thermique Spatiale, Association GOSET, June 1992. 

[9] SET-ATS version 2 User Requirements. C. Puillet, EPSILON Ingenierie, February 1994 

[10] ISO 10303-1 Product Data Representation and 

Exchange - Part 1: Overview and Fundamental Principles. International Organization for Standardization. 

[11] ISO 10303-11 Description Methods: the EXPRESS language reference manual. International 
Organization for Standardization 

[12] Spacecraft Thermal Application Protocol using STEP technology, Association GOSET, December 
1993 


273 



